perf(queue): back off re-evaluating a PR whose verdict never changes - #10204

Closes #10184

metagraphed#8886 was evaluated 56 times on one unchanged commit in 47 minutes — ~1.2/min — producing the identical hold | missing_linked_issue every time. It is CONFLICTING so it cannot merge, held so it does not close, and its linked issue was closed by a merged rival (#10168), so the hold never clears. A state it cannot leave, with nothing throttling re-entry.

Four such PRs produced 66% of all decision records in a two-hour window — the same window that exhausted the installation's GitHub REST quota and stalled 66 queue jobs behind deferred_by: rate_limit.

Why existing coalescing can't help

#10127 collapses simultaneous events. This is a steady drip of legitimately distinct deliveries (CI completions, label writes, sibling activity) arriving long after any window. The missing control is a different kind — not "collapse events that arrive together" but "stop asking a question whose answer has not changed."

Design

Sameness is the decision fields (action, reason_code, hold_cause), deliberately not record_digest: #8886 has 56 distinct digests for 56 identical verdicts because the digest commits to per-evaluation data. Using it would make every repeat look novel — which is how this went unnoticed.

• Record at the persistDecisionRecord call site — the single ledger write every verdict passes through, so no path bypasses it (the same reasoning that function uses for its own re-evaluation check).
• Skip after the actuation-lock claim and before the refresh: the check is one cache read on a pass that already owns the PR, and a backed-off pass spends nothing. Composes with perf(queue): claim the actuation lock before the refresh it exists to prevent #10181.
• Returns rather than throws — not contention, no work to retry, published state already correct. Uses false, this function's existing "did not re-review" signal. No caller branches on it, so it cannot drive a retry loop. Releases the lock first.
• State keyed on the head SHA, so a new commit resets structurally rather than by a remembered rule.

HOLDS ONLY — the flaw that wiring exposed

The first version backed off any repeated verdict. The force-fresh-rebase test (#9497/#2552) caught it: three deliberate identical passes spend the 24h update-branch cap, and my backoff swallowed the third.

"Same verdict" is not "nothing happened." A pass can take real actions — update-branch, cap accounting — while its verdict is unchanged; throttling that suppresses progress, not waste. A hold is the one action meaning "the gate declined to act", so repeating it genuinely produces nothing. Every other action keeps today's behaviour exactly, and this still covers the motivating case precisely (#8886 is 56 identical holds).

This is the whole argument for not shipping the module unwired — 21 passing unit tests could not have found it.

Safety

Capped delay (stuck PRs still revisited, just not 1.2×/min) · fails OPEN on missing/malformed/absent state or a throwing cache · engages only after 3 repeats so an ordinary webhook/sweep race is unaffected.

Verification

Full suite 26,444 passed; the 2 failures are load-sensitive selfhost-ai subprocess tests unrelated to this change — 240 pass in isolation. typecheck, dead-exports, dead-source-files clean.

Mutation-tested, each caught: remove the cap (liveness — PR never revisited) · fail closed on missing state · don't reset on a changed verdict · drop the calls-equivalent hold restriction.

Mutation testing also deleted code: an exponent clamp that looked like defence-in-depth but that no test could distinguish, because Math.min(Infinity, cap) is already the cap.